home *** CD-ROM | disk | FTP | other *** search
/ Power Tools 1993 October - Disc 2 / Power Tools (Disc 2)(October 1993)(HP).iso / hotlines / cpethl / tpcinfo.txt < prev   
Text File  |  1992-08-06  |  12KB  |  218 lines
  1. Transaction Processing Performance Council
  2.  
  3. by Peter Friedenbach, DMSD
  4.  
  5. Management Summary
  6.  
  7. The Transaction Processing Performance Council (TPC) is one of several
  8. consortiums working on industry wide performance benchmark standards.
  9. It was founded in 1988 through the initiative of Omri Serlin, an
  10. industry analyst in transaction processing systems.  This paper
  11. provides an introduction to the TPC, giving some history behind the
  12. council and explaining the purpose and direction of the future
  13. activities of the council.
  14.  
  15. Introduction
  16.  
  17. Originally created in 1988 to address the benchmark abuses centered
  18. around the Debit-Credit and TP1 benchmarks, the TPC has embarked on a
  19. mission to provide a rich set of benchmark suites that will enable a
  20. better environment for competitive performance comparisons across
  21. diverse hardware and software platforms.  To this end the council is
  22. nearing the completion of its second formal benchmark specification and
  23. has already laid the foundation for more specifications to follow.
  24.  
  25. As an organization, the TPC is truly international, made up of 35
  26. member companies representing a wide spectrum of the computer industry.
  27. Everything from big American systems vendors (HP, IBM, Digital, etc.),
  28. major foreign computer companies (NEC, Fijitsu, Hitachi, Bull, etc.),
  29. as well as major database software vendors (Computer Associates,
  30. Oracle, etc.) are members of the council.  The council membership
  31. includes the world's ten largest information technology suppliers, and
  32. 21 of the top 50, as identified in the Datamation 100 list (Datamation
  33. June 15, 1990).
  34.  
  35. While the council is currently made up almost entirely of information
  36. technology suppliers, it is not the intention to limit membership to
  37. just vendors.  Instead, the council is an open forum and encourages
  38. membership from major customers, consulting firms, and industry
  39. analysts involved in the transaction processing marketplace.
  40.  
  41. As a product, the council publishes benchmark specifications that
  42. regulate the running and reporting of transaction processing
  43. performance data.  It is the goal of each specification to provide a
  44. "level playing field" by which customers are able to make objective
  45. comparisons among performance data published by competing vendors on
  46. different system platforms.  Formal implementation of each benchmark is
  47. left to the test sponsor, given the regulations specified within the
  48. standard and the availability of a required full disclosure report.
  49. While it is not a formal requirement, vendors reporting TPC numbers are
  50. strongly urged to have an outside auditor certify the validity of the
  51. performance claims.
  52.  
  53. TPC Benchmark A
  54.  
  55. When the council first started, the number one priority was to reach a
  56. standard definition of the perceived "de facto" standard Debit-Credit
  57. benchmark.  Up to that point Debit-Credit , and it's derivative TP1,
  58. were the only perceived standards in the transaction processing market.
  59. Unfortunately Debit-Credit was not a real industry standard.  The only
  60. public definition of the benchmark appeared in a Datamation article in
  61. 1985.  In many cases, the benchmark in the article was very loosely
  62. defined.  In other circumstances, the definition contained elements
  63. that were overly specific and not readily available across multiple
  64. systems.  In general, vendors who published Debit-Credit numbers took
  65. liberties to redefine the benchmark to match the strengths of their
  66. systems with little recourse from the industry and the marketplace.
  67.  
  68. In November of 1989, the TPC formally published its first benchmark
  69. specification, TPC Benchmark A (TPC-A).  TPC-A represents a milestone
  70. in that it is the first time over 30 computer vendors reached agreement
  71. on the basic framework by which OLTP performance measurements should be
  72. conducted.
  73.  
  74. TPC-A is a system level benchmark that tests the fundamental components
  75. of an OLTP system.  While TPC-A is in part derived from the original
  76. Debit-Credit definition, the two benchmarks should not be compared.
  77. TPC-A is a formal benchmark specification, which leaves little room for
  78. vendors to re-interpret the benchmark.  While the workload of the
  79. benchmark bears some resemblance to Debit-Credit , much of the work
  80. that went into TPC-A deals with more global issues of what constitutes
  81. legitimate benchmarking practices that will also be applicable to other
  82. specifications that the council may develop in the future.
  83.  
  84. An often heard complaint about TPC-A is that it is not a representative
  85. benchmark, as anyone who has been associated with its development will
  86. quickly agree.  The benchmark should be viewed as a lightweight
  87. reproducible transaction stressing simple elements that are fundamental
  88. components in most transaction processing systems.  While the
  89. description of the benchmark has strong overtones of a banking
  90. application, it is only an aid in describing the workload.  a real user
  91. application is a much more complex workload made up, in part, of a
  92. series of simple actions tested in TPC-A.
  93.  
  94. Because TPC-A is not a representative benchmark, it is a mistake to
  95. consider using it for capacity planning.  When used properly, TPC-a is
  96. a means of doing a first cut qualification for users looking at
  97. purchasing a new system.  To a customer looking for a specific level of
  98. performance, TPC-A will help delineate the wide range of potential
  99. system choices and provide a focused subset that the user can further
  100. refine based upon other selection criteria.  TPC-A should never be used
  101. as a substitute for a specific customer application benchmark when
  102. critical capacity planning and/or product evaluation decisions are
  103. involved.
  104.  
  105. TPC Benchmark B
  106.  
  107. Having successfully completed work on TPC-A, the council then set out
  108. to address the benchmarking abuses associated with the TP1 benchmark.
  109. The second official specification of the council, TPC Benchmark B (TPC-
  110. B), is the result of this effort and is currently going through formal
  111. approval by the council.  If, as expected, two-thirds of the council
  112. members approve the specification, it will become a formal standard.
  113. Completion of the approval process is expected in September 1990.
  114.  
  115. For the council, TPC-B is an exercise in how to convert a system level
  116. benchmark into a more specific test of the abilities of the database
  117. subsystem.  In past TP1 measurements, there was little consistency in
  118. the tricks vendors used to adapt the original Debit-Credit system
  119. benchmark to a more simplistic database test.  The result was a set of
  120. performance claims that could not be compared, thrust upon the user
  121. community under the notion of standard TP1 performance measurements.
  122. In deriving TPC-B from TPC-A, the council deliberately spelled out the
  123. exact rules by which vendors can execute and report test results and
  124. therefore, avoid past comparison problems with TP1 measurements.
  125.  
  126. TPC-B is a database level benchmark that tests the database system
  127. fundamentals common in transaction processing.  In essence, TPC-B is a
  128. stress test of the database system's ability to handle transaction
  129. processing.  TPC-B performance numbers should never be compared with
  130. the more general system performance of TPC-A.  In practice, TPC-B
  131. numbers should be much higher than those of TPC-A and should show
  132. significantly lower price-performance.
  133.  
  134. As with TPC-A, TPC-B is not a representative benchmark and, therefore,
  135. is not meant for capacity planning.  TPC-B should be used instead as a
  136. first cut qualification for users looking to purchase a new database
  137. management system.  TPC-B should never be used as a substitute for a
  138. specific customer application benchmark when critical capacity planning
  139. and/or product evaluation decisions are involved.
  140.  
  141. TPC Workload Spectrum
  142.  
  143. While TPC-A and TPC-B represent major steps toward true industry
  144. standard benchmarks, the council still recognizes that these benchmarks
  145. represent a limited portion of the entire transaction processing
  146. market.  To put direction into its' future standards, the council took
  147. some time to reflect on the requirements of the transaction processing
  148. market and defined a vision for future benchmark development.  Out of
  149. this effort has come the definition of the TPC Workload Spectrum.
  150.  
  151. The TPC Workload Spectrum views the transaction processing benchmark
  152. arena as made up of several different sectors, each representing one or
  153. more benchmarks that address a certain aspect of transaction
  154. processing.  The sectors are not meant to represent distinct partitions
  155. of the transaction processing market and in many cases there is
  156. overlap.  Rather, the sectors are meant to provide definition and focus
  157. of the activities of the council.  Currently the five sectors within
  158. the spectrum are:
  159.  
  160.      Basic System OLTP Services
  161.      Business Application Services
  162.      Database Stress Tests
  163.      Real Time Services
  164.      Complex Data Services
  165.  
  166. The Basic System OLTP Services sector currently encompasses only one
  167. benchmark, TPC-A.  As a separate category, TPC-A represents a test of
  168. fundamental elements present in all OLTP applications.
  169.  
  170. The Business Application Services sector actually represents six
  171. distinct benchmark definitions that, in total, define a set of
  172. application services common to most businesses.  Five of the six
  173. benchmarks within the sector are individual workloads focused at
  174. different functional areas of a business (Order Processing, Inventory
  175. Control, Customer Support, Accounting, Decision Support).  The sixth
  176. workload will be a composite mix of the previous five.  The goal of the
  177. Business Application Services sector is to develop a set of benchmarks,
  178. all based upon a common database, representative of real applications
  179. found in todays corporations.
  180.  
  181. The Database Stress Tests sector is made up of a set of diverse tests
  182. that exercise different aspects of database management systems.
  183. Currently the council knows of three benchmarks that could be defined
  184. for this sector.  TPC-B, which is close to being a formal standard, is
  185. a good test of the transaction processing capabilities of a database
  186. system.  The council also sees opportunities for a decision support
  187. benchmark focused on the complex queries found in Executive Information
  188. Systems.  A further test exploring the performance of database
  189. utilities and operations is another potential event.
  190.  
  191. The Real Time Services sector is made up a set of benchmarks, as yet
  192. unspecified, that address the real time requirements of data
  193. acquisition, process control, and message processing.  In similar
  194. fashion, Complex Data Services sector also represents a set of
  195. benchmarks that will address the requirements associated with complex
  196. data formats found in records management, document management, and
  197. objects.
  198.  
  199. With the adoption of the TPC Workload Spectrum, the council has a
  200. vision to guide all future benchmarks.  The council is currently
  201. pursuing two specifications within subcommittees.  One addresses the
  202. Order Processing portion of the Business Application Services and the
  203. other addresses the Executive Information System portion of the
  204. database stress tests.  As time and resources become available in the
  205. future, the council will address the other portions of the spectrum.
  206.  
  207. Conclusion
  208.  
  209. It has been almost two years since the TPC was created and with the
  210. pending approval of TPC-B, the council will have finally completed its
  211. original objectives.  With the adoption of the TPC Workload spectrum as
  212. a guide, the council has a clear vision of where it would like to take
  213. industry standard transaction processing benchmarks in the future.  A
  214. real momentum has developed within the council and the TPC should be
  215. able to deliver on its' promise of a rich set of standard benchmarks
  216. that provide users with a better environment in which to do competitive
  217. performance comparisons of transaction processing systems.
  218.